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Field of the Invention 

15 The invention relates generally to client-server networks. More specifically, the 

invention relates to a method for informing a client system of application programs 
installed at server systems that are available to the client system for execution. 

Background of the Invention 

Contemporary computer networks consist of a number of computer systems, 

20 called nodes, communicating with other computer systems via communication links. 

Typically, some of the nodes are client nodes and other nodes are server nodes. A client 
node formulates and delivers queries to a server node. A user of the client node enters the 
queries through a user interface operating on the client node. The server node evaluates 
the queries and delivers responses to the client node for display on the client user 

25 interface. 





Usually, the server nodes host a variety of application programs that can be 
accessed and executed by client nodes. When a client node launches an application 
program, the execution of that application program can occur at either the client node or 
the server node, depending upon the computing model followed by the computer 
5 network. In a server-based computing model, the server node executes the application 
program, and only the control information for the client user interface is transmitted 
across the computer network to the client node for display. In a client-based computing 
model, the server node transmits the application program to the client node so that the 
client node can run the program using the resources of the client node. 

10 One drawback of contemporary computer networks is that client nodes may be 

unaware of the application programs available for use on the server nodes. In fact, client 
nodes may not even be aware of each available server node on the network. To find 
available application programs on a particular server node, a user of the client node may 
need to find and gain access to that server node and perform a directory listing of the files 

15 existing on that server node. Even then, this listing might not indicate to the user those 
applications which the user is authorized to use. 

Moreover, once the user is aware of the application programs on a server node, 
often that user must establish a link to those applications. Industry has developed 
software tools to aid the user in creating these links, e.g.. Remote Application Manager 

20 manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Florida. The Remote 
Application Manager is an application program installed on the client node. This 
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application program g>Ud« an administrator of the cUent node to enter information tl^ 
establishes a linic to an application published on a particular server node. The 
administrator supplies such fafo^ation as the name of the session, the protocol for 
accessing the server node, the server name or IP address or the published application. 
5 Approaches of this kind require that the administmtor know fl,e information and 
understand the details of protocols and domains in order to establid, the connection. 

Summary of the Invention 

The present invention enables the user of a client system to become informed 
about available application programs on servers in a network witi,ou, requiring fl,e user to 
.0 know where to find such applications or to enter technical infonnation necessaty to Ifak 

to such applications. 

In one aspect, the mvention relates to a method for ptesenting application 
programs to a client system in a network includmg U,e diem system and a plurality of 
servets. The servers include a host server a«, receives application-telated infonnation 

15 ^"'^^ix.nding.oapplicationprogramshos.edbyaplurali.yofserversinanetwork. User 
credentials ate received from the client system. Wrether each hosted application program 
is available to the client system for execution is detetmined based on tite user credentials 
and the received application-related infonnation. Infonnation is transmittal from tire host 
server to the client system indicating to the client system each hosted application that is 
20 available to tiie client system for execution. In some embodiments, me host server 
creates an output display containing tite application-related infonnation, such as a 
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HyperText Markup Language (HTML) file, an Extended Markup Language (XML), or 
other Structured General Markup Language (SGML) file. 

The host server can authenticate the cUent system based on received user 
credentials. When the client system selects one of the available applications for 
5 execution, that application can be executed without requiring additional input of user 
credentials by a user of the client system, although the selected application is at a setver 
Other than the host server. 

In one embodiment, a comiection is established between the client system and the 
host server using an Independent Computing Architecture (ICA) protocol. The ICA 
10 protocol can establish a virtual chamiel to transmit information to the client system 
indicating each hosted application program that is available to the client system. 
A request to execute one of the available hosted apphcation programs can be received on 
the comiection. In response to the request, a second comiection between the client system 
and the host server can be established to exchange information associated with an 
15 execution of the requested apphcation program. In another embodiment, a comiection 
between the host server and a second server hosting the requested application can be 
established in response to the request. Infomiation associated with an execution of the 
requested apphcation program can be exchanged between the second server and the client 
system via the host server. 

20 A second request to execute a second one of the available hosted application 

programs can be received on the comiection between the host server and the client 
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system. Another connection between the host server and a third server hosting the 
requested application can be established in response to the second request. Information 
associated v^th an execution of the second requested application program can be 
exchanged between the third server and the client system via the host server. Information 
5 received from the second and third servers can be merged for transmission to the client 
system. 

In still another embodiment, application information can be provided by the host 
server to the client system in response to the first request. A second connection can be 
established between the client system and a second server hosting the requested 
10 application in response to the provided application information. 

The host server can transmit the available application information in response to a 
request by the client system. The transmitted information can produce a graphical user 
interface display at the client system having icons representing the available application 
programs. The transmitted information can also disclose each hosted application program 
15 that the client system is unauthorized to use. 

The host server can communicate with each of the other servers to determine the 
application programs hosted by those other servers and to develop a database for storing 
the application-related information. The database can be accessible to each of the other 
servers of the plurality, or each of the other servers can maintain a database for storing the 
20 application-related information. 
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In another aspect, the invention relates to a method for presenting to a client 
system each application hosted by a server that is available to the client system. User 
credentials are received from the client system. Application-related information is 
maintained by the server. Whether each application hosted by the server is available to 
5 the client system for execution is determined based on the user credentials and the 

application-related information. Information indicating each application that is available 
to the client system is transmitted from the server to the client system. 

In another aspect, the invention relates to a server comprising a service module 
that collects application-related information corresponding to application programs 

10 hosted by the plurality of servers. A database stores the collected application-related 
information. A receiver receives user credentials from the client system. The service 
module determines for each application program hosted by the plurality of servers 
whether that hosted application program is available for use by the user of the client 
system based on the user credentials and the application-related information stored in the 

15 database. A transmitter transmits information to the client system. 

The service module can transmit a datagram to other servers in the plurality to 
collect the application-related information corresponding to the application programs 
hosted by those servers. The transmitted information discloses to a user of the client 
system each hosted application program that is available for use by the user of the client 

20 system. The transmitter can transmit available application information using a virtual 
chaimel communications protocol. 
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Brief Description of the Drawings 
The invention is pointed out with particularity in the appended claims. The above 
and further advantages of the invention may be better understood by referring to the 
following description in conjunction with the accompanying drawings, in which: 
5 Fig. 1 is a diagram of an embodiment of client nodes in communication with a 

group of server nodes via a network, wherein a program neighborhood of a client node 
can be determined according to the principles of the invention; 

Fig. 2A is a block diagram illustrating an exemplary process by which one of the 
server nodes can initiate execution of an application program for determining the program 
10 neighborhood of a client node; 

Fig. 2B is a block diagram illustrating an exemplary process by which a client 
node can initiate execution of an application program for determining the program 
neighborhood of that client node; 

Fig. 2C is a block diagram illustrating an exemplary process by which a client 
15 node uses a web browser application to determine its program neighborhood; 

Figs. 3A, 3B, and 3C are block diagrams illustrating exemplary processes by 
which a client node can launch an application program from a Program Neighborhood 
window displayed at that client node; 

Figs. 3D is a block diagram illustrating an exemplary process by which a client 
20 node can launch an application program from a Program Neighborhood web page 
displayed at that client node; 
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Fig. 4 is a block diagram of a client-based computing embodiment in which a 
client node having an installed program neighborhood application of the invention is in 
communication with one of the server nodes; 

Fig. 5 is a block diagram of a server-based computing embodiment in which a 
5 client node is in communication with a server node having an installed program 
neighborhood application program of the invention; 

Fig. 6A is a screen shot of an exemplary display on the display screen of a client 
node after the program neighborhood application program of the invention is executed; 
Fig. 6B is a screen shot of another exemplary display on the display screen of a 
10 client node after the program neighborhood application program of the invention is 
executed; 

Fig. 7 is a flow chart representation of an embodiment of a process by which a 
client node is informed as to the availability for use of application programs on the 
application servers. 

15 Detailed Description of the Invention 

FIG. 1 shows a first computing system (client node) 10 and a second computing 
system (client node) 20 in communication with computing systems (application servers) 
30, 32, 34, and 36 over a network 40. The network 40 can be a local-area network (LAN) 
or a wide area network (WAN) such as the Internet or the World Wide Web. Users of the 

20 client nodes 1 0, 20 can be connected to the network 40 through a variety of connections 
including standard telephone lines, LAN or WAN links (e.g., Tl, T3, 56kb, X.25), 
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broadband connections (ISDN, Frame Relay, ATM), and wireless connections. The 
connections can be established using a variety of communication protocols (e.g., TCP/IP, 
IPX, SPX, NetBIOS, Ethernet, RS232, and direct asynchronous connections). 

The client node 10 can be any personal computer (e.g., 286, 386, 486, Pentium, 
5 Pentium II, Macintosh computer), Windows-based terminal. Network Computer, wireless 
device, information appliance, RISC Power PC, X-device, workstation, mini computer, 
main frame computer or other computing device that has a windows-based desktop and 
sufficient persistent storage for executing application programs downloaded from the 
application servers 30, 32, 34 across the network 40. Windows-oriented platforms 

10 supported by the client node 10 can include Windows 3.x, Windows 95, Windows 98, 
Windows NT 3.51, Windows NT 4.0, Windows CE, Macintosh, Java, and Unix. The 
client node 10 can include a display screen 12, a keyboard 14, memory 16 for storing 
downloaded application programs, a processor 17, and a mouse 18. The memory 16 can 
provide persistent or volatile storage. The processor 17 can execute the application 

15 programs locally on the client node 10 and display a resulting windows-based desktop on 
the display screen 12. Such local processing on the client node 10 is according to the 
above-described client-based computing model. 

Altematively, the client node 20 can be any terminal (windows or non-v^ndows 
based), or thin-client device operating according to a server-based computing model. In a 

20 server-based computing model, the execution of application programs occurs entirely on 
the application servers 30, 32, 34, and the user interface, keystrokes, and mouse 
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movements are transmitted over the network 40 to the client node 20. The user interface 
can be text driven (e.g., DOS) or graphically driven (e.g., Windows). Platforms that can 
be supported by the client node 20 include DOS and Windows CE for windows-based 
terminals. The client node 20 includes a display screen 22, a keyboard 24, a mouse 28, a 
5 processor (not shown), and persistent storage (not shown). 

The application servers 30, 32, 34, and 36 can be any computing device that 
controls access to other portions of the network (e.g., workstations, printers). It is to be 
understood that more or fewer application servers can be connected to the network 40. 
The servers 30, 32, 34, and 36 can operate according to either a client-based computing 

10 model or a server-based computing model as described above. 

Each application server 30, 32, 34, and 36 hosts one or more application programs 
that can be accessed by the client nodes 10 and 20. Applications made available to client 
nodes for use are referred to as published applications. Examples of such applications 
include word processing programs such as MICROSOFT WORD® and spreadsheet 

15 programs such as MICROSOFT EXCEL®, both manufactured by Microsoft Corporation 
of Redmond, Washington, financial reporting programs, customer registration programs, 
programs providing technical support information, customer database applications, or 
application set managers. 

The servers 30, 32, and 34 can belong to the same domain 38. In the network 40, 

20 a domain is a sub-network comprising a group of application servers and client nodes 
under control of one security database. A domain can include one or more "server 
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farnis." (A server farm is a group of servers that are linked together to act as a single 
server system to provide centralized administration.) Conversely, a server farm can 
include one or more domains. For servers of two different domains to belong to the same 
server farm, a trust relationship may need to exist between the domains. A trust 
5 relationship is an association between the different domains that allows a user to access 
the resources associated with each domain with just one log-on authentication. 

In one embodiment, the application server 36 is in a different domain than the 
domain 38. In another embodiment, the appUcation server 36 is in the same domain as 
servers 30, 32, and 34. For either embodiment, application servers 30, 32, and 34 can 
10 belong to one server farm, while the server 36 belongs to another server farm, or all of the 
application servers 30, 32, 34, and 36 can belong to the same server farm. When a new 
server is connected to the network 40, the new server joins either an existing server farm 
or starts a new server farm. 

The network 40 can include a master server node for performing load-level 
15 balancing among the application servers 30, 32, 34, and 36. The master server node can 
be one of the application servers 30, 32, 34, or 36. The master server node includes a list 
of server addresses and load information corresponding to each of the other application 
servers. The master server node can direct the client node to a particular server node on 
which to execute an application based on the list of available servers and corresponding 
20 load levels. Alternatively, the application servers 30, 32, 34, 36 may collaborate among 
themselves in a peer-to-peer fashion in order to exchange administration information such 



-11- 




as load levels, allowing any server 30, 32, 34, 36 to respond to a request made by a client 

node 10, 20. 

Program Neighborhood 

According to the principles of the invention, a user of either client node 10, 20 is 
5 able to learn of the availability of application programs hosted by the application servers 

30, 32, 34, and 36 in the network 40 without requiring the user to know where to find 

such applications or to enter technical information necessary to link to such applications. 

These available application programs comprise the "program neighborhood" of the user. 

A system for determining a program neighborhood for a client node includes an 
10 application program (hereafter referred to as the "Program Neighborhood" application), 

memory for storing components of the application program, and a processor for executing 

the application program. 

The Program Neighborhood application can be installed in memory of the client 

node 10 and/or on the application servers 30, 32, 34, and 36 as described below. The 
15 Program Neighborhood application is a collection of services, applications program 

interfaces (APIs), and user interface (UI) programs that disclose to users of the client 

nodes 10, 20 those application programs hosted by the application servers that each client 

node is authorized to use (e.g., execute). 

An application server operating according to the Program Neighborhood 
20 application collects application-related information from each of the application servers 

in a server farm. The application-related information for each hosted application can be a 
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variety of information including, for example, an address of the server hosting that 
application, the application name, the users or groups of users who are authorized to use 
that application, and the minimum capabilities required of the client node before 
establishing a connection to run the application. For example, the application may stream 
5 video data, and therefore a required minimum capability is that the client node supports 
video data. Other examples are that the client node can support audio data or can process 
encrypted data. The application-related information can be stored in a database as 
described later in the specification. 

When a client node logs onto the network 40, the user of the client node provides 

10 user credentials. User credentials typically include the usemame of the client node, the 
password of the user, and the domain name for which the user is authorized. The user 
credentials can be obtained from smart cards, time-based tokens, social security numbers, 
user passwords, personal identification (PE^) numbers, digital certificates based on 
symmetric key or elliptic curve cryptography, biometric characteristics of the user, or any 

15 other means by which the identification of the user of the client node can be obtained and 
submitted for authentication. The server responding to the client node can authenticate 
the user based on the user credentials. The user credentials can be stored wherever the 
Program Neighborhood application is executing. When the client node 10 executes 
Program Neighborhood application, the user credentials can be stored at the client node 

20 10. When an application server is executing the Program Neighborhood, the user 
credentials can be stored at that server. 
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From the user credentials and the application-related information, the server can 
also determine which application programs hosted by the application servers are available 
for use by the user of the client node. The server transmits information representing the 
available application programs to the client node. This process eliminates the need for a 
5 user of the client node to set-up application connections. Also, an administrator of the 
server can control access to applications among the various client node users. 

The user authentication performed by the server can suffice to authorize the use of 
each hosted application program presented to the client node, although such applications 
may reside at another server. Accordingly, when the client node launches (i.e., initiates 

10 execution of) one of the hosted applications, additional input of user credentials by the 
user may be unnecessary to authenticate use of that application. Thus, a single entry of 
the user credentials can serve to determine the available applications and to authorize the 
launching of such applications without an additional, manual log-on authentication 
process by the client user. 

15 Either a client node 10, 20 or an application server can launch the Program 

Neighborhood application as described in connection with Figs. 2A-2C. The results are 
displayed on the display screen 12, 22 of the client node 10, 20. In a graphical windows- 
based implementation, the results can be displayed in a Program Neighborhood graphical 
window and each authorized application program can be represented by a graphical icon 
20 in that window. 
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One embodiment of the Program Neighborhood application filters out application 
programs that the client node 10, 20 is unauthorized to use and displays only authorized 
(i.e., available) programs. In other embodiments, the Program Neighborhood application 
can display authorized and unauthorized applications. When unauthorized applications 
5 are not filtered from the display, a notice can be provided indicating that such 

applications are unavailable. Alternatively, the Program Neighborhood application can 
report all applications hosted by the application servers 30, 32, 34, 36 to the user of a 
client node, without identifying which applications the client node 10, 20 is authorized or 
unauthorized to execute. Authorization can be subsequently determined when the client 

10 node 10, 20 attempts to run one of those applications. 

Fig. 2A shows an exemplary process by which a server launches the Program 
Neighborhood (PN) application and presents resuhs of the PN application to the client 
node 1 0. The server can launch the PN application in response to a request 42 by the 
client node 10 for a particular application program. The request passes to the master 

15 server node, in this example server 30. The master server node 30, taking load-balancing 
and application availability into account, indicates (arrow 43) to the client node 10 that 
the sought-after application is available on server 32. The client node 10 and server 32 
establish a connection (arrows 45 and 46). By this connection, the server 32 can transfer 
the executable code of the particular application to the client node 10, when the client 

20 node 10 and server 32 are operating according to the client-based computing model. 
Altematively, the server 32 can execute the particular application and transfer the 
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graphical user interface to the client node 10, when the client node 10 and server 32 are 
operating according to the server-based computing model. In addition, either the master 
server node 30 or the server 32 can execute the Program Neighborhood application 41 
and push the results (arrows 43 or 46) back to the client node 10 so that when the client 
5 node 10 requests the Program Neighborhood application, the program neighborhood is 
already available at the client node 10. 

Fig. 2B shows another exemplary process by which the client node 10 initiates 
execution the Program Neighborhood application and a server presents the results of the 
PN application to the client node 10. The client node 10 launches the Program 
10 Neighborhood application (e.g., by clicking on the Program Neighborhood icon-^ 

V 

representing the application). The request 50 for the Program Neighborhood application 
is directed to the master server node, in this example server 30. The master server node 
30 can execute the Program Neighborhood application, if the application is on the master 
server node 30, and return the results to the client node 10. Alternatively, the master 
15 server node 30 can indicate (arrow 5 1) to the client node 1 0 that the Program 

Neighborhood application 41 is available on another server, in this example server 32. 
The client node 10 and server 32 establish a connection (arrows 53 and 54) by which the 
client node 10 requests execution of the Program Neighborhood application 41. The 
server 32 can execute the application 41 and transfer the results (i.e., the graphical user 
20 interface) to the client node 1 0. 
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Fig. 2C shows another exemplary process by which a client node 10 initiates 
execution of the Program Neighborhood application, in this example via the World Wide 
Web. A client node 20 executes a web browser application 80, such as NETSCAPE 
NAVIGATOR, manufactured by Netscape Communications, Inc. of Mountain View, 
California or MICROSOFT INTERNET EXPLORER, manufactured by Microsoft 
Corporation of Redmond, Washington. 

The client node 20, via the web browser 80, transmits a request 82 to access a 
Uniform Resource Locator (URL) address corresponding to an HTML page residing on 
server 30. In some embodiments the first HTML page returned 84 to the client node 20 
by the server 30 is an authentication page that seeks to identify the client node 20. 

The authentication page allows the client node 20 to transmit user credentials, via 
the web browser 80, to the server 30 for authentication. Transmitted user credentials are 
verified either by the server 30 or by another server in the farm. This allows a security 
domain to be projected onto the server 30. For example, if the server 30 runs the 
WINDOWS NT operating system, manufactured by Microsoft Corporation of Redmond, 
Washington, and the authenticating server runs the UNIX operating system, the UNIX 
security domain may be said to have been projected onto the server 30. User credentials 
may be transmitted "in the clear," or they may be encrypted. For example, user 
credentials may be transmitted via a Secure Socket Layer (SSL) connection, which 
encrypts data using the RC3 algorithm, manufactured by RSA Data Security, Inc. of San 
Mateo, California. 
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The server 30 may verify the user credentials received from the client node 20. 
Alternatively, the server 30 may pass the user credentials to another server for 
authentication. In this embodiment, the authenticating server may be in a different 
domain from the server 30. Authenticated user credentials of the client node 20 may be 
stored at the client node 20 in a per-session cookie, in fields that are not displayed by the 
web browser 80, or in any other manner common in maintenance of web pages. In some 
embodiments, a server farm with which the server 30 is associated may allow guest users, 
i.e., users that do not have assigned user credentials, to access applications hosted by 
servers in the farm. In these embodiments, the authentication page may provide a 
mechanism for allowing a client node 20 to identify that it is a guest user, such as a 
button or menu selection. In other of these embodiments, the server 30 may omit the 
authentication page entirely. 

Still referring to Fig. 2C, once the client node 20 is authenticated by the server 30, 
the server prepares and transmits to the client node 20 an HTML page 88 that includes a 
Program Neighborhood window 58 in which appears graphical icons 57, 57' representmg 
application programs to which the client node 20 has access. A user of client node 20 
invokes execution of an application represented by icon 57 by clicking that icon 57. 

Fig. 3 A shows an exemplary process of communication among the client node 10, 
the master server node, in this example server 30, and the server 32. The client node 10 
has an active connection 72 with the server 32. The client node 10 and server 32 can use 
the active connection 72 to exchange information regarding the execution of a first 
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application program. The user credentials of the client node 10 are stored at the client 
node. Such storage of the user credentials can be in cache memory or persistent storage. 

In this embodiment, the Program Neighborhood application runs on the client 
node 10. The client node display has a Program Neighborhood window 58 in which 
5 appears a graphical icon 57 representing a second application program. A user of the 
client node 10 can launch the second application program by double-clicking the icon 57 
with the mouse. The request passes to the master server node 30 via a connection 59. 
The master server node 30 indicates to the client node 10 via the connection 59 that the 
sought-after application is available on server 32. The client node 10 signals the server 

10 32 to establish a second connection 70. The server 32 requests the user credentials from 
the client node 10 to authenticate access to the second application program. Upon a 
successfiil authentication, the client node 10 and server 32 establish the second 
connection 70 and exchange information regarding the execution of the second 
application program. Accordingly, the client node 10 and the server 32 communicate 

15 with each other over multiple connections. 

Fig. 3B shows an exemplary process of communication among the client node 20, 
the master server node, in this example server 30, and servers 32, 34, and 36. The client 
node 20 has an active connection 73 with the server 32. The client node 20 and server 32 
can use the active connection 73 to exchange information regarding the execution of a 

20 first application program. The user credentials of the client node 20 are stored at the 
server 32 in cache memory or in persistent storage. 
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In this embodiment, the Program Neighborhood application runs on the server 32. 
The server 32 includes software providing a server-based client engine 62, enabling the 
server 32 to operate in the capacity of the client node 20. The client node 20 display has 
a Program Neighborhood window 58 in which appears graphical icons 57, 57' 
representing a second application program and a third application program, respectively. 
A user of the client node 20 can launch the second application program by double- 
clicking the icon 57. The request to launch the second application program passes to the 
server 32 via active connection 73, and the server 32 forwards the request to the master 
server node 30 (arrow 65). 

The master server node 30 indicates (arrow 65) to the server 32 that the sought- 
after application is available on server 34. The server 32 contacts the server 34 to 
establish a connection 66. To authenticate access to the application, the server 34 obtains 
the user credentials of the client node 20 from the server 32. The server 32 and server 34 
establish the connection (arrow 66) by which the server 32 requests execution of the 
second application and the server 34 returns the graphical user interface results to the 
server 32. The server 32 forwards the graphical user interface resuhs to the client node 
20, where the results are displayed. Accordingly, the information exchanged between the 
client node 20 and the server 34 "passes through" the server 32. 

Similarly, the client node 20 can launch the third application program by double- 
clicking the icon 57'. The request to launch the third application program passes to the 
server 32. The server 32 forwards the request to the master server node 30, which 
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considers load-balancing and application program availability to determine which server 
can handle the request. In this example, the master server node indicates that server 36 
can run the third application program. 

The server 32 and^erver 36 establish a connection (arrow 74) by which the server 
5 32 requests execution of the third application program, and the server 36 returns the 
graphical user interface results to the server 32. To permit execution of the third 
application program, the server 36 can authenticate the user credentials of the client node 
20, which are obtained from the server 32. The server 32 forwards the graphical user 
interface results to the client node 20 where the results are displayed. Accordingly, the 

10 results of executing the third application program pass between the client node 20 and the 
server 36 through the server 32. 

From this illustration it should be understood that client node 20 can run multiple 
application programs through one connection with the server 32, while the server 32 
maintains muhiple connections (in this example, one connection with server 34 and a 

15 second connection with server 36). Also, the server 32 merges the information received 
from the server 34 with the information received from the server 36 into one data stream 
for transmission to the client node 20. 

Fig. 3C shows an exemplary process of communication among the client node 20, 
the master server node, in this example server 30, and servers 32 and 34. The client node 

20 20 has an active connection 76 with the server 32. The client node 20 and server 32 can 
use the active connection 76 to exchange information regarding the execution of a first 
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application program. The client node 20 can store the user credentials in cache memory 
or in persistent storage. 

In this embodiment, the Program Neighborhood application runs on the server 32. 
The client node 20 display has a Program Neighborhood window 58 in which appears a 
5 graphical icon 57 representing a second application program. A user of the client node 20 
can launch the second application program by double-clicking the icon 57. The request 
to launch the second application program passes to the server 32. The server 32 responds 
(i.e., "calls back") to the client node 20 by returning application-related information such 
as the name of the application and capabilities needed by the client node 20 for the 

10 second application to run. 

With the information provided by the server 32, the client node 20 then 
communicates with the master server node 30 via connection 77 to determine the server 
for executing the second application program. In this example, that server is server 34. 
The client node 20 then establishes a connection 78 to the server 34. Server 34 requests 

15 the user credentials from the client node 20 to authenticate the user of the client node 20. 
The second application program executes on the server 34, and the server 34 returns the 
graphical user interface to the client node 20 via the established connection 78. 
Accordingly, the client node 20 can have multiple active connections between the 
multiple servers. 

20 Fig. 3D shows an exemplary process of communicating between the client node 

20, a server 30 that in this example acts as a web server, and server 32. The client node 
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20 authenticates itself to the server 30 as described above in connection with Fig. 2C. In 
one embodiment, the server 30 accesses an output display template 90, such as an SGML, 
HTML or XML file, to use as a base for constructing the Program Neighborhood window 
to transmit to the client node 20. The template may be stored in volatile or persistent 
5 memory associated with the server 30 or it may be stored in mass memory 92, such as a 
disk drive or optical device, as shown in Fig. 3D. 

In this embodiment, the template 90 is a standard SGML, HTML, or XML 
document containing Program Neighborhood-specific tags that are replaced with dynamic 
information. The tags indicate to the server 30 where in the output display to insert 

10 information corresponding to available applications, such as icon images. In one 

particular embodiment, the Program Neighborhood-specific tags are embedded withm 
comments inside,^file, allowing the file to remain compatible with standard 
interpreters. In another embodiment, the Program Neighborhood-specific tags are 
extensions of the markup language used as the base for the template, 

15 Examples of HTML tags that may be used in a template in accordance with the 

present invention are set forth below in Table 1 : 



TABLE 1 



Tag 


Description 


ControlField field value 


This tag is used to set the value of data that either persists 
between Program Neighborhood web pages, are set by the 
user, or are used to help in cross page navigation, such as 
user name, domain, password, template, and application. 


DrawProgramNeighborhood 


His tag is used to draw a Program Neighborhood display 
at this location in an output display. 
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AppName 


This tag is replaced by the name of the pubUshed 
application in the current context. 


WindowType 


This tag is replaced by the window type of the published 
application in the current context. 


WindowHeight 


This tag is replaced by the window height of the published 
application in the current context. 


WindowWidth 


This tag is replaced by the window width of the published 
application in the current context. 


WindowScale 


This tag is replaced by the window scale of the published 
application in the current context. 


WindowColors 


This tag is replaced by the color depth of the published 
application in the current context. 


SoundType 


This tag is replaced by the soxrnd setting of the published 
application in the current context. 


VideoType 


This tag is replaced by the video setting of the published 
application in the current context. 


EncryptionLevel 


This tag is replaced by the encryption level of the 
published application in the current context. 


Icon 


This tag is replaced by the icon of the published 
application in the current context. 



Other tags can be provided to set control fields and to provide conditional processing 
relating to the Program Neighborhood application. 

In one embodiment, the template is constructed dynamically using, for example, 
5 COLD FUSION, manufactured by Allaire Corp. of Cambridge, Massachusetts or 
ACTIVE SERVER PAGES manufactured by Microsoft Corporation of Redmond, 
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Washington. Alternatively, the template may be static. The Program neighborhood 
application parses the template, replacing Program Neighborhood-specific tags as noted 
above. Tags that are not Program Neighborhood-specific are left in the file to be parsed 
by the browser program 80 executing on the client 20. 

In one embodiment, a template parser object is provided that accepts an HTML 
template as input, interprets Program Neighborhood-specific tags present in the template, 
and output the original template with all Program Neighborhood tags replaced with 
appropriate text. The template parser object can be passed a cookie, a URL query string, 
or a control field from a web server interface to provide the information with which 
Program Neighborhood-specific tags should be replaced. 

In another embodiment, the Program Neighborhood application allows scripts to 
access to information via an application programming interface. Scripts may be written 
in, for example, VBScript or Jscript. In this embodiment, the scripting language is used 
to dynamically generate an output display using information returned by the application 
in response to queries posed by the script. Once the output display is generated, it is 
transmitted to client node 20 for display by the browser program 80. 

A user of the client node 20 can launch an application by double-clicking with a 
mouse an icon 57, 57' displayed in the Program Neighborhood web page. In some 
embodiments, each icon 57, 57' is an encoded URL that specifies: the location of the 
application (i.e., on which servers it is hosted or, alternatively, the address of a master 
server); a launch command associated with the application; and a template identifying 
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how the output of the application should be displayed (i.e., in a window "embedded" in 
the browser or in a separate window). In some embodiments, the URL includes a file, or 
a reference to a file, that contains the information necessary for the client to create a 
connection to the server hosting the application. This file may be created by the Program 
5 Neighborhood application dynamically. The client node 20 establishes a connection 

(arrow 94) with the server identified as hosting the requested application (in this example, 
server 32) and exchanges information regarding execution of the desired application. In 
some embodiments, the connection 94 is made using the Independent Computing 
Architecture (ICA) protocol, manufactured by Citrix Systems, Inc. of Fort Lauderdale, 

10 Florida. Thus, the client node 20 may display application output in a window separate 
from the web browser 60, or it may "embed" application output within the web browser. 

Fig. 4 illustrates an exemplary arrangement of program components for a client- 
based implementation of the Program Neighborhood application. A client-based 
implementation of Program Neighborhood application can be used in a network using 

15 either the server-based computing model in which the servers execute the Program 

Neighborhood application or the client-based computing model in which the client node 
10 executes the Program Neighborhood application locally. The Program Neighborhood 
application includes a Program Neighborhood Service (PNSVC) component 44, an 
Application Database component 48, a Program Neighborhood Application Program 

20 Interface (PNAPI) component 52, a Program Neighborhood User Interface component 
56, and a local cache 60. 
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The application server 30, for example, includes the service component (PNSVC) 
44 and the application database 48. The client node 10, which is a representative 
example of a client node that can support a client-based implementation of the Program 
Neighborhood application, includes the application program interface PNAPI 52, the user 
5 interface user interface component 56, and the local cache 60 components. The PNAPI 
52 communicates with the user interface component 56 and the local cache 60. The 
PNSVC 44 communicates with the application database 48 and with the PNAPI 52 on the 
client node 10 via communications link 62. 

The communications link 62 can be established by, for example, using the ICA 
10 protocol. ICA is a general-purpose presentation services protocol designed to run over 
industry standard network protocols, such as TCP/IP, IPX/SPX, NetBEUI, using 
industry-standard transport protocols, such as ISDN, frame relay, and asynchronous 
transfer mode (ATM). The ICA protocol provides for virtual channels, which are 
session-oriented transmission connections that can be used by application-layer code to 
15 issue commands for exchanging data. The virtual channel commands are designed to be 
closely integrated with the functions of client nodes. One type of virtual channel 
connection supported by the ICA protocol is a Program Neighborhood virtual channel. 

The Program Neighborhood virtual channel protocol can include four groups of 
commands: 

20 (1) initialization-related commands; 
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(2) single authentication related commands that can be supported by each 
client node wanting a copy of the user credentials; 

(3) application data related commands for implementing the Program 
Neighborhood user interface; and 

5 (4) application launch callback-related commands for running the user 

interface on an application server. 

Application Database 

The application database 48 is a cache of the authorized user and group 

information for all the public (i.e., published) applications in a server farm or in a group 
10 of trusted domains. Each server in a server farm can maintain its o\m application-related 

information in persistent storage and build up the database 48 in volatile storage. In 

another embodiment, all collected application-related information in the database 48 can 

be stored in persistent storage and made accessible to each other server in the server farm. 

The database 48 can be implemented in a proprietary format (e.g., as a linked list in 
15 memory) or using Novell's Directory Services (NDS) or any directory service adhering to 

the X.500 standard defined by the Intemational Telecommunication Union (ITU) for 

distributed electronic directories. 

The application database 48 includes a list of application servers. Each server in 

the list has an associated set of applications. Associated with each application is 
20 application-related information that can include the application name, a list of servers, 

and client users that are authorized to use that application. An overly-simplified example 

of the application-related information maintained in the database is illustrated by the 
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following Table 1. Users A and B are users of the client nodes 10, 20, "n/a" indicates 
that the application is hosted, but is not available to client node users, and "-" indicates 



that the application is not hosted. 



TABLE 2 



Server Name 


Spreadsheet 


Applicat] 


ions 








Customer Database 


Word Processor 


Calculator 


Server 30 


User A 


UserB 


n/a 




Server 32 


UserB 


n/a 


User A 




Server 34 








User A 
UserB 



Table 1 shows a list of servers 30, 32, 34, the applications hosted by the servers, 
(Spreadsheet, Customer Database. Word Processor, and Calculator), and those users who 
are authorized to use the applications. For example, server 30 hosts the Spreadsheet 
program, the Customer Database and the Word Processor. User A is authorized to use 
the Spreadsheet, User B is authorized to use the Customer Database, and no users are 
authorized to use the Word Processor. It is to be understood that other techniques can be 
used to indicate who is authorized to use a particular application. For example, the user 
information stored in the database can be used to indicate those users who are 
unauthorized to use a particular application rather than those who are authorized. 

To obtain the information that is stored in the database 48, the server 30 obtains 
the application-related information from each other server in the server farm regarding 
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the applications on those servers, including control information that indicates which 
client users and servers are permitted to access each particular application. The 
application-related information maintamed in the database may or may not persist across 
re-boots of the server 30. 

5 The application database 48 can be a central database that is stored at the 

application servers 30 and is accessible to all of the servers in the server fann. 
Accordingly, the application-related information can be available for use by other servers 
such as those servers that perform published application authentication during session 
log-on and appHcation launching. In another embodiment, the application database 48 
10 can be maintained at each of the application servers based upon the information that each 
server obtains from communications with each other server in the server farm. 
Program Neighborhood Service Program (PNSVC^ 

Each server 30, 32, 34 and 36 having the Program Neighborhood application 
installed thereon executes the PNSVC software 44. The PNSVC software 44, operating 
15 on each server 30, 32, 34 and 36 establishes a communication link (e.g., a named pipe) 
with each other server. The servers 30, 32, 34 and 36 exchange the application-related 
information on the named pipes. In another embodiment, the PNSVC software 44 
collects the application-related information from the other servers in the server farm 
through remote registry calls (e.g., the service component 44 transmits a datagram to 
20 other servers in the plurality requesting the application-related information corresponding 
to the application programs hosted by those servers). The PNSVC 44 software also 
maintains the relationships of groups and users to published applications in the 
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application database 48 and accesses the information when authenticating a client 
An administrator of the server 30 can use a user interface to configure the PNSVC 44. 

Other functions of the PNSVC software 44 include implementing the services and 
functions requested by the PNAPI 52 and communicating with the PNAPI 52 on the 
5 client node 1 0 using a Program Neighborhood virtual device driver (VDPN). The VDPN 
operates according to the Program Neighborhood virtual channel protocol described 
above for establishing and maintaining an ICA connection. 

Program Neighborhood Application Program Interface rPNAPT^ 

The PNAPI 52 is a set of sofhvare functions or services that are used by the 
10 Program Neighborhood application to perfonn various operations (e.g., open windows on 
a display screen, open files, and display message boxes). The PNAPI 52 provides a 
generic mechanism for launching application objects (e.g., icons) produced by nmning 
the Program Neighborhood application and application objects in a legacy (i.e., 
predecessor or existing for some time) client user interface. When the client node 10 
15 launches an available application, the launch mechanism can launch the application on 
the server 30, if necessary (e.g., when the client node 10 does not have the resources to 
locally execute the application). 

The PNAPI 52 provides all puWished application infonnation to the user interface 
component 56 for display on the screen 12 of the client node 10. The PNAPI 52 also 
20 manages server farm log-ons in a local database of logon credentials (e.g., passwords) for 
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users of the client node 10 to support the single authentication feature. Credentials may 
or may not be persistent across bootings (power-off and on cycles) of the client node 10. 

The PNAPI 52 provides automatic and manual management for Program 
Neighborhood application objects stored in the local cache 60. The local cache 60 can 
5 either be refreshed manually by the user of the client node 10, or at a user-definable 
refresh rate, or by the server at any time during a connection. In a Windows 
implementation, the PNAPI 52 can build remote application file associations and manage 
the "Start" menu and desktop icons for application object shortcuts. 

Program Neighborhood User Interface 
10 The user interface module 56 interfaces the PNAPI 52 and can be a functional 

superset of an existing client-user interface (e.g., Remote Application Manager). The 

user interface module 56 accesses the information stored in the local cache 60 through the 

PNAPI 52 and visually presents that information to the user on the display screen 12 of 

the client node 10. The displayed information is a mixture of information generated by a 

15 user of the client node 10 andinformation obtained by the Program Neighborhood 

application. The user interface module 56 can also show the user all applications that the 
user is currently running and all active and disconnected sessions. 

In a windows-based embodiment, the user interface module 56 can present a 
variety of graphical components, such as windows and pull-down menus, to be displayed 

20 on the display screen 12. A display of a combination of such graphical user interface 
components is generally referred to as a "desktop." A desktop produced by the user 
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interface module 56 can include a Program Neighborhood window displaying the 
neighborhood of application programs available to the user of the client node 10 for use. 
These application programs are a filtered combination of the published applications 
hosted by a server farm on the network. The user interface module 56 can generate a 
5 Program Neighborhood window for each server farm or merge the applications from 
different server farms under a single Program Neighborhood window. 

At a top level, the Program Neighborhood window includes a folder for each 
server farm. Clicking on one of the folders with the mouse 1 8 produces a window 
containing a representation (e.g., an icon) of each hosted application available to the user, 
10 e.g., see Figs. 6A and 6B. The Program Neighborhood window becomes the focal point 
for launching published applications, and the user interface module 56 can be used to 
launch applications through the PNAPI 52. For example, the user of the client node 10 
can use the mouse 1 8 to select one of the displayed icons and launch the associated 
application. 

15 A feature of a client-based implementation is that the user can browse the objects 

displayed in the Program Neighborhood window although the client node is offline, that 
is, the ICA connection 62 is inactive. Also, a user of the client node 10 can drag 
application objects and folders out of the Program Neighborhood v^ndow and into other 
graphical components (e.g., other windows, folders, etc.) of the desktop. 

20 Fig. 5 shows an exemplary arrangement of program components for a server- 

based implementation of the Program Neighborhood application. The components 
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include a Service (PNSVC) component 44', an Application Database component 48', an 
Application Program Interface (PNAPI) component 52', a User Interface component 56' 
and a local cache 60'. Each software component 44', 48', 52', 56', and 60' is installed on 
the application server 30'. The software components for the server-based implementation 
5 correspond to the software components for the client-based implementation of Fig. 4. 
The fiinctionality of each server-based software component is similar to the client-based 
counterpart, with differences or added capabilities described below. The PNSVC 44' 
communicates with the application database 48' and with the PNAPI 52' using local 
procedure calls. The PNAPI 52' also commimicates with the user interface module 56' 

10 and the local cache 60'. 

Similar to that described in Fig. 4 for the client node 10, the client node 20 logs 
on to the network 40, the server 30' develops and maintains a database containing the 
application related information collected fi"om the other servers 32, 34 in the server farm, 
and a communication link is established between the server 30' and the client node 20. 

15 The appUcation server 30' is in communication with the client node 20 via an ICA 

channel connection 62'. The channel connection 62' can be established by an ICA virtual 
channel protocol (e.g., Thinwire). The Thinwire protocol can be used to transmit 
presentation commands from Windows-based applications running on the application 
server 30' to the client node 20. To a user of the client node 20, the applications appear 

20 to be running on the client node 20. The client node 20 can include a Remote 
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Application Manager application program 64 that communicates with the application 
server 30' via the ICA channel connection 62'. 

To run the Program Neighborhood application in a server-based implementation, 
the user of the client node 20 connects to an initial desktop (at the server 30') and 
5 launches the Program Neighborhood application from v^ithin that desktop environment. 
The connection to the initial desktop can occur automatically, e.g., via a logon script of 
the client node 20, via an entry in the StartUp group in Windows 95, or by another 
centrally managed server specific mechanism. All remote application management and 
launching is accomplished through this initial desktop. 

10 Similar to that described in Fig. 4 for the server 30, the server 30' uses the user 

credentials to determine those application programs that are authorized for use by the user 
of the client node 20. A Program Neighborhood graphical window is returned to the 
client node 20 and displayed on the client screen 22. This window can contain icons 
representing the available and, possibly, the unavailable application programs that are in 

15 the program neighborhood of the client node 20. 

The user of the client node 20 can select and launch one of the application 
programs displayed in the Program Neighborhood window. When launching an 
application, the Program Neighborhood application can execute the application on the 
same server 30', where applicable, taking into account load balancing requirements 

20 among servers and the availability of the application on that server 30'. The PNAPI 52' 
can include a launch mechanism for launching a remote application locally on the server 
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30' when the server 30' is nominated to launch the application. When a different server 
is needed to run the application, the Program Neighborhood application can launch the 
application via the server 30' (i.e., server-based client) using the windows to present the 
application on the desktop of the client node 20 as described above in Fig. 3B. 
5 In one embodiment, the web-based Program Neighborhood application includes a 

group of objects that manage various aspects of the application. In one embodiment, the 
application includes three primary object classes that "plug in" to a web server: a gateway 
object class; a credentials object class; and an applications object class. In some specific 
embodiments, the object classes are provided as Java beans. The three primary object 

10 classes facilitate: validation of user credentials into a server farm; generation of lists of 
published applications that a specified user may access; provision of detailed information 
about a specific published application; and conversion of published application 
information into an ICA-compatible format. 

When provided as Java beans, the objects can be accessed in a number of different 

15 ways. For example, they may be compiled as COM objects and made available to the 
web server as ActiveX components. In another embodiment, the Java beans can be used 
in their native form, such as when the server uses Java Server Pages technology. In yet 
another embodiment, the Java beans can be instantiated and used directly in a Java 
servlet. In still another embodiment, the server 30 can instantiate the Java beans as COM 

20 objects directly. 
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A credentials object class manages information necessary to authenticate a user 
into a target server farm. A credentials object passes stored user credentials to other 
Program Neighborhood objects. In some embodiments, the credentials object is an 
abstract class that camiot be instantiated and represents a user's credentials. Various class 
5 extensions may be provided to allow different authentication mechanisms to be used, 
including biometrics, smart cards, token-based authentication mechanisms such as 
challenge-response and time-based password generation, or others. For example, a "clear 
text credentials" extension may be provided that stores a user's name, domain, and 
password in plain text. 

10 A gateway object class handles communications with a target server farm. In one 

embodiment, the gateway object class is provided as an abstract Java class that camiot be 
instantiated. A particular gateway object may retrieve application information by 
communicating with a seiver farm using a particular protocol, reading cached application 
information, a combination of these two methods, or other various methods. 
15 As noted above, the gateway object class caches information to minimize 

communication with a target server farm. Extensions to the gateway object may be 
provided to communicate with the semr farm over specific protocols, such as HTTP. In 
one embodiment, an extension class is provided that allows the gateway object to 
communicate with the server farm via WINDOWS NT named pipes. The gateway object 
20 may provide an application programming interface hook that allows other Program 
Neighborhood objects to query the object for application information. 
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An applications object class contains information about published applications 
and returns information about applications hosted by the server farm in order to create the 
Program Neighborhood web page. The applications object class creates objects 
representing applications by retrieving information relating to the applications, either 
5 from an object created by the gateway object or directly from the servers in the server 
farm. An applications object acts as a container for certain properties of the application, 
some settable and some not settable, such as: the name of the application (not settable); 
the percentage of the client's desktop that the client window should occupy (settable); the 
width of the client window, in pixels, for this application (settable); the height off the 

10 client window, in pixels, for this application (settable); the number of colors to use when 
connecting to the application (settable); the severity of audio bandvsddth restriction 
(settable); the level of encryption to use when connecting to the application (settable); the 
level of video to use when connecting to this application (settable); whether the 
application should be placed on a client's start menu (settable); whether the application 

15 should be placed on the client's desktop (settable); the identity of the Program 

Neighborhood folder to which the application belongs (settable); the description of the 
application (settable); the source of the graphics icon file for the application (settable); 
the type of v^ndow that should be used when connecting to the application (not settable); 
and whether to override default parameters for the object. 

20 Fig. 6A is a screenshot of an exemplary Program Neighborhood window 120 that 

can be displayed on the screen 18, 22 of either client node 10, 20 after the Program 
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Neighborhood application has executed. The window 120 includes graphical icons 122. 
Each icon 122 represents an application program that is hosted by one of the servers 30, 
32, 34 and 36 on the network 40. Each represented application is available to the user of 
the client node for execution. The user can select and launch one of the applications 
5 using the mouse 18, 28 or keyboard 14, 24. 

Fig. 6B is a screenshot of another exemplary Program Neighborhood window 124 
that can be displayed on the screen 18, 22 of either client node 10, 20 after the Program 
Neighborhood application has executed. The window 124 includes graphical icons 126, 
128. Each icon 126, 128 represents an application program that is hosted by one of the 

10 servers 30, 32, 34 and 36 on the network 40. Each application program represented by 
one of the icons 126 is available to the user of the client node 10, 20 for execution. The 
user can select and launch one of the applications using the mouse 18, 28 or keyboard 14, 
24. For web-based program neighborhood environments, the screenshots of Figs. 6A and 
6B are similar, except that icons 122, 166, 128 are displayed within a browser window. 

15 Each application program represented by one of the icons 128 is unavailable to 

the user of the client node 1 0, 20, although such applications are present in the server 
farm. The unavailability of these application programs can be noted on the display screen 
(e.g., "X"s can be dravra through the icons 128). An attempt to launch such an 
application program can trigger a message indicating that the user is not authorized to use 

20 the application. 
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Fig. 7 shows an exemplary process by which a user of either client node 10, 20 
can be informed about the availability of applications hosted by application servers 30, 
32, 34 and 36 on the network 40. In step 80, the client node 10, 20 requests log-on 
service from one of the servers, e.g., server 32. The server 32 requires valid user 
5 credentials to establish the comiection. The server 32 receives the user credentials from 
the cliem node 10 (step 82), and authenticates the user for log-on (step 84). A desktop is 
displayed at the client node 10, 20 (step 85). The desktop can include a graphical icon 
representing the Program Neighborhood application program. 

In step 86, the application server 32 establishes a connection with each other 
10 servers 30, 34 and 36 to exchange application-related information, as described above, 
corresponding to application programs hosted on those servers (step 88). In step 90, the 
application server 32 develops and maintains a database of the collected application- 
related information. Each other server 30, 34, 36 in the server farm can develop a 
database equivalent to the database of the server 32 and in similar mamier as the server 
15 32. In another embodiment, the database of the server 32 can be a centralized database 
that is accessible to each other application server 30, 34, 36 in the server farm. The 
collecting of application-related information can occur independently or be friggered by 
the request of the client node 10, 20 to log-on to the server farm 38. 

In step 92, the client node 10, 20 can request execution of an application program 
20 from the desktop display. The master server node can process the request and, using a 
load-balancing evaluation and application availability as described above, determine the 
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application server to provide the service to the cUent node 10, 20 (step 94). For example, 
the application server 32 can be selected to service the request with the client node 10, 20. 
In step 96, the client node 10, 20 establishes a communications link with the server 32. 
The server 32 and the client node 10, 20 can communicate according to the ICA protocol 
5 appropriate for that client node as described above. 

Also in response to this request to run the application program, the master server 
node 30 or the server 32 can run the Program Neighborhood application (step 93) and 
push the results to the client node 10, 20, although the client node 10, 20 may not have 
requested the PN application program. When executing the PN application program, the 

10 master server node 30 or server 32 filters the application-related information in the 
database using the user credentials (step 100). The result of filtering the database 
determines those application programs that are authorized for use by the user of the client 
node 10, 20. The authorized application programs are in the program neighborhood of 
the client node 10, 20. This program neighborhood of available application information 

15 is pushed to the client node 10, 20 (step 102) and displayed on the client screen 12, 22 in 
a Program Neighborhood graphical window (step 104). 

In other embodiments, the Program Neighborhood window may include 
applications that are in the server farm but unavailable for use to the client node 10, 20. 
In a Windows-based implementation, the available (and unavailable) application 

20 programs can be represented by icons. The user of the client node 10, 20 can select and 
launch one of the application programs displayed in the Program Neighborhood window. 
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The present invention may be provided as one or more computer-readable 
programs embodied on or in one or more articles of manufacture. The article of 
manufacture may be a floppy disk, a hard disk, a CD ROM, a flash memory card, a 
PROM, a RAM, a ROM, or a magnetic tape. In general, the computer-readable programs 
5 may be implemented in any programming language. Some examples of languages that 
can be used include C, C+-I-, or JAVA. The software programs may be stored on or in 
one or more articles of manufacture as object code. 

While the invention has been shown and described vwth reference to specific 
preferred embodiments, it should be understood by those skilled in the art that various 
10 changes in form and detail may be made therein without departing from the spirit and 
scope of the invention as defined by the following claims. 
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